The present invention generally relates to database server acceleration and more specifically database server acceleration using non-volatile memory-based storage devices and cache acceleration software.
FIG. 1a shows a typical computer storage system. An application 100 will generally use standard application programming interfaces (APIs) provided by the operating system 110 to access functions for interfacing with system components such as graphics, storage, and networking. Storage APIs will generally be offered in terms of standard file-based operations including create, delete, open, close, read, write, append, etc. In each case, the operation will reference a file object. The operating system 110 will then use the services of a file system (filesystem) layer 120 which in turn uses a block-based disk subsystem 130 to issue basic block I/O disk commands to a physical bulk storage disk 140, which may be a hard disk drive (HDD) or solid-state drive (SSD).
Applications that require a high number of reads and writes (e.g. database applications) are typically limited by the latency and throughput of the data storage system. An SSD can provide much lower latency and better throughput performance than an HDD, but SSDs are much more expensive than HDDs and it may not be economical to implement a storage system for a large database purely with SSDs. However, applications can be accelerated more cost-effectively by placing frequently used data in a high-performance cache, such as a flash-based non-volatile memory cache, while retaining an HDD for the bulk or less frequently accessed data.
FIG. 1b shows such a computer storage system, where a non-volatile memory acceleration cache 135 is inserted in a storage stack between the block-based disk subsystem 130 and the disk 140. In this position, the acceleration cache 135 can inspect all the block I/O commands directed to the disk 140, all data being sent to the disk 140, and all data being returned from the disk 140. The acceleration cache 135 can choose to accelerate disk read, disk writes, or both. The general principle is that a data read can be serviced more quickly by reading the data from the acceleration cache 130 rather than the disk 140 or a data write may be serviced more quickly by writing the data to the acceleration cache 135 (to be written to the disk 140 at some later time when the disk 140 may be idle or not frequently accessed).
However, because of the position of the acceleration cache 135 in the storage stack, the acceleration cache 135 only sees raw disk I/O commands and therefore has no knowledge of a file system or file systems being used, which files and directories are being accessed, or which application is issuing the storage API command to access the storage (since there may be multiple applications running on the operating system 110). The acceleration cache 135 will therefore base its caching (cacheing) decisions based on criteria such as, but not limited to, the frequency of accesses to data according to a block address being accessed.
At least to begin with, all data accesses may be cached, but as the space in the acceleration cache 135 is limited, there may be no more space for new data accesses to be saved in the acceleration cache 135. In this case, criteria may be applied to select previous cache entries for removal to make space for the new entries. For example, an algorithm may be employed to select previous cache entries which are the Least Recently Used (LRU) or Least Frequently Used (LFU).
Regardless of what types of algorithms may be used to populate or de-populate the acceleration cache 135, they can only use the information that is available at the acceleration cache layer, which are commands to read or write blocks of data at specific addresses. This information does not enable the acceleration cache 135 to decide to add or remove cache entries based on what application 100 has issued the storage command, or the files that contain these blocks of data. The acceleration cache 135 is therefore unaware of the applications, files, and file systems being accessed.
SQL Server® is an example of a relational database management system developed by Microsoft Corporation. As a database application, it is a software product whose primary function is to store and retrieve data as requested by other software applications, be it those on the same computer or those running on another node across a network (including, but not limited to, the Internet).
As discussed above, the computer storage system represented in FIG. 1b provides a general cache system to provide storage disk command acceleration. However, a general solution does not provide a targeted or efficient acceleration performance in a situation such as a computer storage system running multiple applications. For example, the application may only access selected databases or even selected file groups or files. The computer storage system of FIG. 1b is not capable of individually accelerating these databases, file groups, or files. In addition, an individual node may run other activities which utilize the resources used as the acceleration cache 135. As such, the acceleration speed of the specific databases, file groups, or files being accessed by an application will likely be reduced as the resources will be equally utilized by any application running on the operating system of that node, which may include accesses originating from other nodes if they are operating in a network.
These issues are partially addressed in the computer storage system of FIG. 1c. Here, a file caching layer 115 is provided between the operating system 110 and the file system 120. In this case, the file caching layer 115 intercepts all the file system commands directed to the file system 120.
Unlike the example illustrated in FIG. 1b which is intimately involved with basis disk I/O commands, the file caching layer 115 is instead issuing file-based commands to the file system 120. As such, cache storage may now be provided by an SSD 150 where the disk subsystem 130 issues standard block I/O commands to both the SSD 150 and the bulk storage disk 140. The file caching layer 115 may be configured to know where to store cached files (the SSD 150) and the regular bulk files (the disk 140). As such, the file caching layer 115 will have knowledge of file objects being accessed.
However, all storage accesses are originated above and directed through the operating system 110, which makes the accesses anonymous to the file caching layer 115 in terms of the particular application 100 originally making the storage access request to the operating system 110. Hence, without the particular domain knowledge of the particular files and filenames being used, the file caching layer 115 still may not have sufficient knowledge in order to accelerate specific applications or files being used by an application. In general, this may require a considerable amount of user intervention in order to configure the cache, including but not limited to, by first identifying and then indicating to the file caching layer 115 which individual files to accelerate.
A recent version of SQL Server® 2012, includes new features and enhancements such as AlwaysOn® SQL, Server Failover, Cluster Instances, and Availability Groups which provide a set of options to improve database availability; Contained Databases which simplify the moving of databases between instances; new and modified Dynamic Management Views and Functions; programmability enhancements including new spatial features, metadata discovery, sequence objects and the THROW statement; performance enhancements such as ColumnStore Indexes as well as improvements to OnLine and partition level operations and security enhancements including provisioning during setup, new permissions, improved role management, and default schema assignment for groups.
To take advantage of these features and enhancements within a computer storage system of the type represented in FIG. 1b may be difficult, as the acceleration cache 135 is only aware of anonymous disk I/O commands. Similarly, information regarding the specific internal implementation that Microsoft chooses to employ for the organization of the databases, in terms of the directories and file names used, may not be publicly described. It may then require expert knowledge and analysis of the database system in order to determine which files are associated with which databases and features therein. This knowledge is unlikely to be known by a typical database user, nor by designers and architects of the databases, as they deal with higher level constructs and may be completely unaware of the file level implementation details. Therefore, it may also be difficult to configure a file-based caching system of the type illustrated by FIG. 1c to take advantage of these feature and enhancements in a complex relational database product such as Microsoft SQL Server® 2012.
In view of the above, it can be appreciated that there are certain problems, shortcomings or disadvantages associated with the prior art, and that it would be desirable if a computer storage system were available that is aware of databases, file groups, and files on a system in order to provide an efficient acceleration process tailored to the needs of users and capabilities of the database server applications and corresponding hardware.